Detecting transportation company trips in a vehicle based upon on-board audio signals

ABSTRACT

The systems and methods may transmit a plurality of locationing pulse requests from a mobile device in a vehicle to an audio system of the vehicle during a period of operation of the vehicle. The audio system may have an array of speakers disposed inside the vehicle, and the locationing pulse requests may include a request to emit a locationing pulse from the array of speakers. The systems and methods may further receive the locationing pulse at a microphone of the mobile device; and determine, based upon receiving the locationing pulse, that the vehicle was in service of a TNC company, or otherwise operating as a TNC vehicle, during the period of operation based upon passengers entering and leaving the vehicle during the period of operation. Insurance covering the operation of the vehicle for TNC use may be verified, and/or alternatively, offered to facilitate insuring TNC vehicle operation.

CROSS REFERENCE TO RELATED APPLICATIONS

The present disclosure claims the benefit of U.S. Provisional PatentApplication No. 62/570,925, entitled “Detecting Transportation CompanyTrips in a Vehicle Based Upon On-Board Audio Signals” filed on Oct. 11,2017, U.S. Provisional Patent Application No. 62/570,944, entitled“Recommendations to an Operator of Vehicle Based upon Vehicle UsageDetected By In-Car Audio Signals” filed on Oct. 11, 2017, U.S.Provisional Patent Application No. 62/570,956, entitled “Cost SharingBased upon In-Car Audio Signals” filed on Oct. 11, 2017, and U.S.Provisional Patent Application No. 62/570,969, entitled “Cost SharingBased upon In-Car Audio Signals” filed on Oct. 11, 2017, all of whichare hereby incorporated herein by reference in their entirety.

TECHNICAL FIELD

The present disclosure relates generally to detecting transportationnetwork company trips in a vehicle. More particularly, the presentdisclosure relates to detecting transportation network company trips ina vehicle based upon on-board audio signals, and assessing riskassociated with transportation network company trips.

BACKGROUND

With the rise in popularity of ridesharing, transportation networkcompanies (TNC), such as Lyft and Uber, have been able to pairpassengers with a driver who provides the passengers with transportationon the driver's personal vehicle. Conventionally, TNCs offer passengersthe ability to request service via their mobile devices. The mobiledevice may track the location of the driver, and determine when thevehicle will arrive. The TNC may monitor the service. The TNC industryis rapidly changing the livery/taxi industry by using the latest mobiletechnology to facilitate rides for hire.

With these new transportation services in the marketplace, drivers areexposed to new risks. Additionally, personal auto policies may notextend coverage to the use of personal cars as taxis or livery vehicles,including their use in TNC services.

SUMMARY OF THE DISCLOSURE

The present embodiments disclose systems and methods that may generallyrelate to detecting transportation network company (TNC) trips taken bya vehicle, and particularly, inter alia, to detecting TNC trips taken bya vehicle based upon on-board audio signals, and assessing riskassociated with transportation network company trips.

In one aspect, a computer-implemented method for detecting use of avehicle for transportation network company (TNC) trips may be provided.The method may transmit a plurality of locationing pulse requests from amobile device in a vehicle to an audio system of the vehicle during aperiod of operation of the vehicle. The audio system may have an arrayof speakers disposed inside the vehicle, and the locationing pulserequests may include a request to emit a locationing pulse from at leastone of the array of speakers. The method may further receive thelocationing pulse at a microphone of the mobile device, and determine,based upon the receiving operation, that the vehicle was in service of aTNC company, or otherwise operating as a TNC vehicle, during the periodof operation based at least in part on passengers entering and leavingthe vehicle during the period of operation.

The method may not only detect a plurality of TNC passengers (e.g.,based upon geolocating their mobile devices, driving pattern of thevehicle, etc.), each of the plurality of TNC passengers having enteredand left the vehicle over a period of operation of the vehicle, but mayalso detect physical objects occupying a seat of the vehicle. In someembodiments, the method may determine an identity of a driver of thevehicle, where the driver is a party to an insurance agreement insuringthe vehicle. The identity may be determined based upon an applicationexecuting on the mobile device, the application having the identity ofthe driver associated therewith. The insurance agreement may have termsregarding TNC usage of the vehicle. The method may verify whether or notthe vehicle and/or driver are covered or insured for TNC operation. Ifthe method may transmit a notice to the driver that TNC usage is notcovered by a current insurance agreement, such as when vehicle operationindicates the presence of a TNC passenger inside the vehicle, and/orgenerate/transmit an offer for a TNC endorsement and/or an insurancequote for TNC operation. As a result, policyholders may be notified toextend coverage of their personal auto policies to include the use oftheir personal cars in TNC trips, or may be notified in other ways tomitigate risks associated with TNC driving. The method may includeadditional, less, or alternate actions, including those discussedelsewhere herein.

In another aspect, a computer system for detecting use of a vehicle fora transportation network company (TNC) may be provided. The computersystem may include one or more processors and transceivers. The computersystem may include one or more memory units configured to storenon-transitory computer executable instructions, and a processorconfigured to interface with the one or more memory units. The processormay be configured to execute the non-transitory computer executableinstructions to cause the processor to (i) determine that a vehicle isin a period of use, the vehicle having an audio system; (ii) transmit aplurality of requests to the vehicle to emit a locationing pulse fromthe audio system; (iii) receive a plurality of sets of locationing datafrom one or more mobile devices inside the vehicle, the plurality ofsets of locationing data including, or indicating, the presence ofpassengers in the vehicle; and/or (iv) determine whether the period ofuse of the vehicle includes one or more TNC trips or TNC vehicleoperation. The audio system may include an array of speakers and anultrasonic beacon. The plurality of requests to the vehicle to emit alocationing pulse may be received by one of the one or more mobiledevices inside the vehicle. In some embodiments, the processor may befurther configured to recognize route patterns of the vehicle that areindicative of TNC trips based upon the plurality of sets of locationingdata. The locationing data may include a geographical location of atleast one of the one or more mobile devices inside the vehicle.

The processor may be further configured to determine whether the vehicleis operated manually or autonomously while the vehicle is in use. Insome embodiments, the processor may be further configured to receivemobile device information, which may include Bluetooth connectioninformation of the one or more mobile devices inside the vehicle. If thevehicle and/or driver are currently not insured for TNC operation, theprocessor may present an offer for a TNC endorsement or other offer forinsurance covering TNC operation to the driver. The computer system mayinclude additional, less, or alternate functionality, including thatdiscussed elsewhere herein.

In another aspect, a computer-implemented method for detecting TNC tripsin a vehicle may be provided. The method may (i) determine that a firstmobile device is inside a vehicle, the vehicle being operated by adriver and having an array of audio speakers; (ii) transmit at least afirst locationing request to the first mobile device, the firstlocationing request including a request to emit a locationing pulse fromone or more of the audio speakers; (iii) receive first locationing datafrom the first mobile device, the first locationing data including firstoccupancy data of seats in the vehicle; (iv) determine that a secondmobile device is inside the vehicle; (v) transmit at least a secondlocationing request to the first mobile device, the second locationingrequest including a request to emit a locationing pulse from one or moreof the audio speakers; (vi) receive second locationing data from thesecond mobile device, the second locationing data including secondoccupancy data of seats in the vehicle; and/or (vii) determine that thevehicle is operating according to a TNC trip based upon the firstoccupancy data and the second occupancy data.

The first occupancy data may include occupancy of one or more frontseats of the vehicle, and the second occupancy data may includeoccupancy of one or more back seats of the vehicle. The first mobiledevice may be associated with the driver of the vehicle and the secondmobile device may be associated with a TNC passenger of the vehicle. Todetermine whether the vehicle is being operated by the driver, themethod may receive a notification of the identity of the driver from anapplication executing on the first mobile device, and/or receive anotification that the first mobile device is communicatively coupled tothe vehicle and capable of controlling the one or more audio speakers.To determine whether the vehicle is operating according to a TNC trip,the method may repeatedly receive locationing data (including dataindicative of a plurality of sets of passengers entering and leaving thevehicle while the vehicle is being operated by the driver) from thefirst mobile device. Insurance covering the operation of the vehicle forTNC use may be verified, and/or alternatively, offered to facilitateinsuring TNC vehicle operation. The method may include additional, less,or alternate actions, including those discussed elsewhere herein.

Advantages will become more apparent to those of ordinary skill in theart from the following description of the preferred embodiments whichhave been shown and described by way of illustration. As will berealized, the present embodiments may be capable of other and differentembodiments, and their details are capable of modification in variousrespects. Accordingly, the drawings and description are to be regardedas illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The Figures described below depict various aspects of the systems andmethods disclosed therein. It should be understood that each Figuredepicts an embodiment of a particular aspect of the disclosed systemsand methods, and that each of the Figures is intended to accord with apossible embodiment thereof. Further, wherever possible, the followingdescription refers to the reference numerals included in the followingFigures, in which features depicted in multiple Figures are designatedwith consistent reference numerals.

There are shown in the drawings arrangements which are presentlydiscussed, it being understood, however, that the present embodimentsare not limited to the precise arrangements and are instrumentalitiesshown, wherein:

FIG. 1 illustrates a block diagram of an exemplary interconnectedwireless communication system on which the computer-implemented methodsdescribed herein may be implemented;

FIG. 2 illustrates a block diagram of an exemplary computer system thatmay be useful in carrying out the implementations of a system accordingto one embodiment;

FIG. 3 illustrates an exemplary flowchart for detecting or identifyingTNC trips taken by or in a vehicle according to one embodiment;

FIG. 4 illustrates an exemplary flowchart for assessing risk associatedwith TNC trips according to one embodiment;

FIG. 5 illustrates an exemplary interior of a vehicle on which themethods described herein may be implemented;

FIG. 6 illustrates an exemplary interior of a vehicle having a messageindicating that a mobile device of a driver is connected to the vehiclevia a short-range communication protocol;

FIG. 7 illustrates an exemplary interior of a vehicle having a messageindicating that a mobile device of a non-driver passenger is connectedto the vehicle via a short-range communication protocol;

FIG. 8 illustrates an exemplary travel route of a non-TNC trip;

FIG. 9 illustrates an exemplary travel route of a TNC trip; and

FIG. 10 illustrates an exemplary interior of a vehicle having a messagedisplayed to a driver when a TNC trip has been detected, and/orindicated by sensor data collected.

The Figures depict aspects of the present invention for purposes ofillustration only. One skilled in the art will readily recognize fromthe following discussion that alternate aspects of the structures andmethods illustrated herein may be employed without departing from theprinciples of the invention described herein.

DETAILED DESCRIPTIONS

The present embodiments disclose systems and methods that may generallyrelate to detecting transportation network company (TNC) trips by, orassociated with, a vehicle, and particularly, inter alia, to detectingTNC trips taken by a vehicle based upon on-board audio signals, andassessing risk associated with transportation network company trips.

The present embodiments may allow a policyholder to have his/herpersonal auto policy fill in the coverage gaps left by TNC-providedinsurance in order to provide the driver with the full liabilitycoverage limits carried on his/her auto policy during the period of timewhen the driver is available for hire, and during all periods of TNCdriving or vehicle operation. Also, policyholders may either be notifiedto extend coverage of their personal auto policies to include the use oftheir personal cars in TNC trips, and/or to be notified of ways tomitigate risks associated with TNC driving.

The present embodiments may (1) detect TNC operation or rides, and/orride sharing among passengers; (2) generate suggestions to the driver orpassengers (e.g., suggestions to switch drivers, suggestions to makechanges to driving style to improve safety and/or efficiency,suggestions to on purchasing on new vehicle, and suggestions to performneeded vehicle maintenance); (3) facilitate cost sharing (e.g., costsharing among drivers when more than one person drives the same vehicle,sharing carpooling costs or road tripping costs, sharing tolls ortraffic tickets, etc.); and/or (4) altering or adjusting insurance costsbased upon vehicle load, vehicle usage, or vehicle or driver profiles ormodels.

In one aspect, a computer-implemented method and system may detect TNCtrips in vehicle based upon in-car audio signals. An insurer may requirea TNC endorsement or other adjustment to an insurance agreement if thepolicy covers TNC trips. A vehicle may emit audio signals from thevehicle's sound system in a frequency band that is not detectable byhumans. Electronic devices associated with individual passengers in thevehicle may detect the audio signals to reveal configuration informationregarding the inside of the vehicle (e.g., location of the electronicdevice within the vehicle, whether a seat is occupied by a person orthing, etc.). Insurers may detect whether a trip is likely to be a TNCtrip or not to determine risk associated with insuring the vehicle basedon the in-car audio signals (e.g., whether occupants of the vehiclematch a TNC pattern wherein passengers join/leave the vehicle in manytrips without clear start/end points in an area). More TNC trips maytherefore be detected and the risk of insuring a driver who makes TNCtrips may be more accurately determined.

In another aspect, a computer-implemented method and system may generaterecommendations on vehicle operation based upon vehicle usage detectedby in-car audio signals. A vehicle may emit audio signals from thevehicle's sound system in a frequency band that is not detectable byhumans. Electronic devices associated with individual passengers in thevehicle may detect the audio signals to reveal configuration informationregarding the inside of the vehicle (e.g., location of one or moreelectronic devices within the vehicle, whether a seat is occupied by aperson or thing, etc.). Usage patterns of a vehicle or of multiplevehicles operated by the same driver may be detected based upon theconfiguration information detected by an electronic device (e.g.,whether the driver could save money by driving a more efficient car ifseats are usually empty; whether the driver tends to employ dangerous orinefficient driving techniques; whether a fatigued driver could improvesafety by letting another passenger drive; whether a vehicle is likelyto require maintenance; etc.). Recommendations may also be made to avehicle operator for tuning or configuring the vehicle based on thedetected usage patterns (e.g., selection of tires, engine tuningparameters, fuel type, optional equipment, etc.).

In another aspect, a computer-implemented method and system mayfacilitate cost sharing based upon in-car audio signals. A vehicle mayemit audio signals from the vehicle's sound system in a frequency bandthat is not detectable by humans. Electronic devices associated withindividual passengers in the vehicle may detect the audio signals toreveal configuration information regarding the inside of the vehicle(e.g., location of an electronic device within the vehicle, whether aseat is occupied by a person or thing, etc.). The vehicle interiorconfiguration information may include the identity of occupants in avehicle and the electronic device may provide payment capabilities forthe occupants to share costs (e.g., insurance costs, toll costs, fuelcosts, congestion fee costs, depreciation costs, etc.). Knowing theidentity of vehicle occupants also improves cost estimation (e.g., basedupon age and driving experience of occupants; whether occupants havebeen associated with high risk; etc.).

In another aspect, a computer-implemented method and system mayfacilitate assessing vehicle risk based upon in-car audio signals. Avehicle may emit audio signals from the vehicle's sound system in afrequency band that is not detectable by humans. Electronic devicesassociated with individual passengers in the vehicle may detect theaudio signals to reveal configuration information regarding the insideof the vehicle (e.g., location of an electronic device within thevehicle, whether a seat is occupied by a person or thing, etc.). Theconfiguration information may be used to create a customized riskprofile for an individual passenger. A customized risk profile may beused to issue a personal mobility insurance policy based upon thevehicle situations frequency encountered by a passenger and/or ausage-based insurance model.

Audio pings between mobile devices and vehicle-mounted sensors and/ormicrophones may be able identify a location of a mobile device within avehicle, and thus a location of a driver or passenger within the vehicle(assuming the mobile device is on a person's body). For instance,triangulation, time-of-flight, and/or other techniques may be used. If aperson is identified as a driver, their mobile device may collecttelematics data as being relevant to the driver's driving behavior ordriving profile. Conversely, if the person is identified as a passenger,their mobile device may collect telematics data as being relevant todriver behavior associated with the passenger traveling in a vehicle asa passenger, such as being relevant to a mobility or passenger profile.

The driving and/or mobility profiles may also be updated withenvironmental data during vehicle operation, such as weather, traffic,road, congestion, and construction data—which may be collected frommobile device sensors, vehicle-mounted sensors, and/or smartinfrastructure. The driving and/or mobility profiles may be used togenerate usage-based insurance (UBI) quotes for drivers and/orpassengers, and for TNC and non-TNC vehicle operation.

The present embodiments may make recommendations or automatically adjustautonomous vehicle system or feature settings or configurations tooptimize or reduce risk. In some embodiments, a pre-trip offer ofinsurance for a given number of miles at a specific rate per mile may begenerated and transmitted to a user's mobile device or vehicle. Thepre-trip offer may be based upon driver or passenger profiles, currentconditions (such as current weather, road conditions, time of day, timeof year, distance, vehicle attributes, and other or surroundingvehicles), and/or number of passengers.

If two or more people are traveling in the vehicle, the system maydetermine, based upon the current conditions and driving profiles, whichperson is the safest or most risk averse driver given the currentconditions, and generate a recommendation and/or an insurance discountif the safest driver (e.g., husband or wife) drives the vehicle for thegiven trip.

Additionally or alternatively, legs of a trip may be analyzed along withchanging current conditions. A specific driver may be identified ashaving the lowest risk associated with driving the vehicle for a givenleg. A recommendation and/or discount may be presented to the vehicleoccupants if the lowest risk driver drives for each individual leg ofthe trip. As a result, less hard braking may occur, and less maintenanceto the vehicle may be needed if the lowest risk driver drives thevehicle a majority of the time.

Pre-trip or post-trip cost sharing may also be provided. For instance,expenses for gas, vehicle operation or mileage, tires, maintenance,tolls, parking tickets, and/or taxes may be split between vehicleoccupants. The vehicle itself may be interconnected and/or “smart,” andbe capable electronically transferring funds between driver andpassenger financial accounts. In other words, the vehicle itself, and/ormobile devices, may operate as payment devices to share costs associatedwith vehicle operation.

Also, the present embodiments may facilitate matching those persons inthe market for a new vehicle with the safest vehicle for them giventheir driving and/or passenger profile. Discounts on auto insurance maybe provided to those that follow recommendations, and purchase vehiclesrecommended to them based upon their driving and/or passenger profile.

Exemplary Interconnectivity

FIG. 1 illustrates a block diagram of an interconnected wirelesscommunication system 100 on which the methods described herein may beimplemented. The communication system 100 may generally be divided intofront-end components 102 and back-end components 104, both of which mayinclude hardware and software applications, as well as various datacommunications channels for communicating data between the varioushardware and software components. The front-end components 102 maygenerate or collect locationing data from mobile device-mounted sensors,vehicle-mounted sensors, smart infrastructure-mounted sensors, wearableelectronics-mounted sensors, other sensors, or from vehicle systems,such as a sound system (e.g., speaker system 124).

Examples of locationing data include occupancy data that describespassengers or other objects in a vehicle (e.g., identities of thepassengers, age of the passengers, the number of passengers presently inthe vehicle, the number of passengers that have entered or left avehicle over a period of operation of the vehicle, the length of time apassenger was inside the vehicle, etc.) and mobile device identificationdata (e.g., the geographical location of the mobile device of the driveror the geographical location of the mobile devices of passengers withinthe vehicle, which collectively is referred to or interchangeablyreferred to as geolocating mobile devices, or geolocating of mobiledevices).

The front-end components 102 may also generate or collect drivingperformance data (both actual and historical) from mobile device-mountedsensors, vehicle-mounted sensors, smart infrastructure-mounted sensors,wearable electronics-mounted sensors, or other sensors. The drivingperformance data may be in the form of vehicle data, vehicle collisiondata, geographic location data (e.g., GPS data), telematics data (e.g.,vehicle load weight, planned vehicle route, travelled vehicle route,travel route patterns taken by the vehicle, distance that the vehicle isestimated to or has traveled, vehicle configuration, vehicle fuelconsumption, vehicle fuel level, tire pressure, vehicle suspensiontuning setting, vehicle control), mobile device data, vehicle-mountedsensor data (e.g., on-board diagnostics may indicate the transmissionmode the vehicle is in, such as automatic or manual mode), autoinsurance claim data, autonomous vehicle data (e.g., whether autonomousnavigation settings have been engaged), smart infrastructure sensordata, image data, or other data.

Accordingly, the locationing data and driving performance data mayprovide contextual information of the vehicle 108 (e.g., a car, truck)related to occupancy within the interior of the vehicle, traffic,vehicle damage, extent of injuries at a vehicle collision, number andidentification of vehicles involved, dates and times of vehicle use,duration of vehicle use, mobile device GPS location, vehicle GPSlocation, speed, RPM or other tachometer readings of the vehicle,lateral and longitudinal acceleration of the vehicle, environment (e.g.,construction, accidents in the area, weather, road condition), or otherinformation relating to use of the vehicle 108. The locationing data anddriving performance data may be collected before, during, and/or after aperiod of operation of the vehicle.

Front-end components 102 may include on-board computer 114, mobiledevice 110 (e.g., a smart phone, a cellular phone, a tablet computer, aspecial purpose or general use computing device, smart watch, wearableelectronics such as augmented reality appliance, vehicle navigationdevice, dedicated vehicle monitoring or control device, and the likes),one or more sensors 120 associated with vehicle 108, and a communicationcomponent 122. The on-board computer 114 may be a general-use on-boardcomputer capable of performing many functions relating to vehicleoperation or a dedicated computer for autonomous vehicle operation.

Further, the on-board computer 114 may be originally installed by themanufacturer of the vehicle 108, or installed as an aftermarketmodification or addition to the vehicle 108. Examples of sensors 120,which may collect or generate the locationing data and drivingperformance data, include a GPS unit, a digital camera, a video camera,a LIDAR sensor, an ultrasonic sensor, an infrared sensor, an ignitionsensor, an odometer, a system clock, a speedometer, a tachometer, anaccelerometer, a gyroscope, a compass, a geolocation unit, radar unit,and an inductance sensor. For instance, sensors 120, such as cameras,microphones, pressure sensors, thermometers, seat sensors, or similarsensors, may actively or passively scan the interior or passengercompartment of the vehicle 108 to monitor the vehicle operator (e.g.,driver) and/or passengers within the vehicle 108, and to generate orcollect occupancy data. Other sensors 120 (e.g., GPS, accelerometer, ortachometer units) may provide data for determining the location ormovement of the vehicle 108, or the location of the mobile devices 110inside the vehicle 108.

The sensors 120 may be positioned to determine telematics data regardingthe speed, force, heading, and/or direction associated with movements ofthe vehicle 108. Some of the sensors 120 (e.g., radar, LIDAR, or cameraunits) may actively or passively scan the vehicle environment forobstacles (e.g., other vehicles, buildings, pedestrians, etc.),roadways, lane markings, signs, or signals. Regardless of embodiment,the sensors 120 may be removably or fixedly incorporated within orconnected to the on-board computer 114 or the mobile device 110 and maybe disposed in various arrangements.

The on-board computer 114 or mobile device 110 may each be configured toexecute one or more algorithms, programs, or applications to generate,collect, or analyze the locationing data and driving performance datafrom one or more sensors 120 within the vehicle 108. The mobile device110 or on-board computer 114 may be integrated into a single device, andin other embodiments, may be separate devices. For example, the on-boardcomputer 114 or mobile device 110 may process the locationing data todetermine configuration information concerning the interior of thevehicle 108, such as whether a seat is occupied by a person or object,or the locations of other mobile devices 110, during a period of vehicleoperation. In such embodiments, the on-board computer 114 or mobiledevice 110 may further process the locationing data (e.g., occupancydata or mobile device identification data) to determine that the vehicle108 was in service of a TNC company during the period of operation(e.g., if the configuration information suggests that TNC passengers, ortheir mobile devices, have entered or left the vehicle over the periodof operation).

As another example, the on-board computer 114 or mobile device 110 mayeach be configured to execute one or more algorithms, programs, orapplications to generate, collect, or analyze the driving performancedata (both present and historical), which may indicate whether thevehicle 108 is in a period of use, whether vehicle 108 is operatedmanually or autonomously while the vehicle 108 is in use, whethervehicle 108 travelled a route pattern indicative of TNC trips, andwhether the period of use of vehicle 108 includes TNC trips. In suchembodiments, if vehicle 108 is an autonomous vehicle, the on-boardcomputer 114 or mobile device 110 may collect data related to theautonomous features to assist the vehicle operator in operating thevehicle 108.

In some embodiments, the mobile device 110 may supplement the functionsperformed by the on-board computer 114 described herein. In otherembodiments, the on-board computer 114 may perform all of the functionsof the mobile device 110 described herein, in which case no mobiledevice 110 may be present in the system 100. Additionally, the mobiledevice 110 and on-board computer 114 may communicate with one anotherdirectly over link 116 or indirectly over multiple radio links.

In preferred embodiments, the mobile device 110 or on-board computer 114may communicate with a speaker system 124 of the vehicle 108 over radiolink 116, utilizing a short-range communication protocol, such asBluetooth, for instance. The speaker system 124 may include an array ofspeakers disposed inside the vehicle 108. The mobile device 110 oron-board computer 114 may transmit a locationing pulse request to thespeaker system 124 over radio link 116, such as a short-rangecommunication protocol (e.g., Bluetooth). The locationing pulse requestmay include a request for the speaker system 124 to emit a locationingpulse.

In some embodiments, the mobile device 110 or on-board computer 114 maybe triggered to transmit the locationing pulse request. For example, aserver communicatively coupled to the mobile device 110 or on-boardcomputer 114, such as server 140 described below, may first receive,from the mobile device 110 or on-board computer 114, information thatindicates that the mobile device 110 or on-board computer 114 andvehicle 108 are configured to communicate over a short-rangecommunication protocol, such as Bluetooth. Accordingly, the server 140,via a passenger identifier application, may determine that mobile device110 or on-board computer 114 is present inside the vehicle 108. Theserver may then, via the passenger identifier application, generateand/or transmit the location pulse request to the mobile device 110 oron-board computer 114, which may in turn transmit the locationing pulserequest to the speaker system 124 over radio link 116, as describedabove.

In response to receiving the locationing pulse request, the speakersystem 124 may emit a locationing pulse to the interior of vehicle 108.The locationing pulse, such as a discrete audio signal, may be emittedfrom the speaker system 124 in a frequency band outside an audiblefrequency range of humans. Mobile device 110 associated with the driveror any passengers in the vehicle may receive/detect the locationingpulse via a microphone of the mobile device 110, for example.

The mobile device 110 may process the locationing pulse and furtherdetermine configuration information (e.g., locationing data) concerningthe interior of the vehicle 108, such as whether a seat is occupied by aperson or object, detecting passengers that have entered or left thevehicle over a period of operation of the vehicle, or the locations ofother mobile devices 110. For example, the mobile device 110 may comparethe locationing pulse emitted from the speaker system 124 (a pre-definedsequence of high frequency sound components) with the received/detectedlocationing pulse. The presence of passengers or objects in the vehicle108 may alter the sequence of high frequency sound components as thelocationing pulse propagates from the speaker system 124 to the mobiledevice 110. The differences may be analyzed to evaluate theconfiguration information concerning the interior of the vehicle 108.

Another way for the mobile device 110 to process the locationing pulseand further determine configuration information (e.g., locationing data)concerning the interior of the vehicle 108 may be to measure time ofsignal arrival techniques. For example, given that a front left andfront right speaker is present in the vehicle 108, to measure whether apassenger is present in the passenger seat, the mobile device 110 oron-board computer 114 may transmit the locationing pulse request to thespeaker system 124 (i.e., front left and front right speakers), themobile device 110 or on-board computer 114 may record the locationingpulse emitted from the speaker system 124, and the recorded sound may beprocessed by the mobile device 110 or on-board computer 114 to measurethe delay between the locationing pulse output emitted from the frontleft and front right speakers.

The on-board computer 114 or mobile device 110 may also be configured tocommunicate with the vehicle 108 utilizing a Bluetooth communicationprotocol, for instance. As described above, the on-board computer 114 ormobile device 110 may communicate with the speaker system 124 via ashort-range communication protocol such as Bluetooth. In someembodiments, the on-board computer 114 or mobile device 110 maycommunicate with vehicle 108, such as via a vehicle controller (notshown), or a vehicle telephony, entertainment, navigation, orinformation system (not shown) of the vehicle 108 that providesfunctionality other than autonomous (or semi-autonomous) vehiclecontrol.

The communication component 122 may be utilized to transmit and receiveinformation from external sources, including other vehicles,infrastructure, smart home controllers or sensors, or the back-endcomponents 104. To send and receive information, the communicationcomponent 122 may include a transmitter and a receiver (or transceiver)designed to operate according to pre-determined specifications, such asthe dedicated short-range communication (DSRC) channel, wirelesstelephony, Wi-Fi, or other existing or later-developed communicationsprotocols. The received information may supplement the data receivedfrom the sensors 120. For example, the communication component 122 mayreceive information that another vehicle ahead of the vehicle 108 isreducing speed, allowing for adjustments in the operation of the vehicle108.

The front-end components 102 may communicate with the back-endcomponents 104, such as the server 140, via a network 130. As such, theback-end components 104, such as the server via the passenger identifierapplication, may receive locationing data (including occupancy data andmobile device identification data), driving performance data, or both,that was collected by the front-end components 102. The on-boardcomputer 114 and mobile device 110 may be configured to send thelocationing data, driving performance data, or both to and/or receivedata from network 130 using one or more suitable communicationprotocols, such as a Wi-Fi direct protocol, an ad-hoc cellularcommunication protocol, and the likes.

Network 130 may be a proprietary network, a secure public internet, avirtual private network or some other type of network, such as dedicatedaccess lines, plain ordinary telephone lines, satellite links, cellulardata networks, or a combination thereof. Network 130 may be implementedas a wireless telephony network (e.g., GSM, CDMA, LTE, etc.), a Wi-Finetwork (e.g., via one or more IEEE 802.11 Standards), a WiMAX network,a Bluetooth network, and the likes. The network 130 may include one ormore radio frequency communication links, such as wireless communicationlinks 112 and 118 with the mobile device 110 and on-board computer 114,respectively. Where the network 130 comprises the Internet, datacommunications may take place over the network 130 via an Internetcommunication protocol.

Server 140 may receive or collect locationing data, driving performancedata, or both from the front-end components 102 via the network 130,store the received data in database 146 or program memory 160, andprocess the received data. For example, server 140 may determine that avehicle is in a period of use, or determine whether the vehicle isoperated manually or autonomously while the vehicle is in use, basedupon the driving performance data. Server 140 may further determinewhether the period of use of the vehicle includes TNC trips based uponthe locationing data (e.g., occupancy data). As another example, server140 may recognize route patterns of the vehicle that are indicative ofTNC trips based upon both the locationing data and driving performancedata. The server 140 may also communicate information associated withthe received or processed data back to the front-end components 102.

The server 140 may comprise a controller 155 that is operativelyconnected to the database 146 via a link 156. The controller 155 mayalso be operatively connected to the network 130 via a link 135. Thecontroller 155 may include a program memory 160, a processor 162, arandom-access memory (RAM) 164, and an input/output (I/O) circuit 166,all of which may be interconnected via an address/data bus 165.Similarly, the memory of the controller 155 may include multiple RAMs164 and multiple program memories 160. The RAM 164 and program memory160 may be implemented as semiconductor memories, magnetically readablememories, or optically readable memories, for example.

The program memory 160 may store various software applications, whichmay include the passenger identifier application 142, a vehicle monitorapplication 143, a TNC route auditor application 144, and a TNC tripdetector application 145. The vehicle monitor application 143 maydetermine that vehicle 108 is in a period of use (or otherwise determineperiods of use), and whether vehicle 108 is operated manually orautonomously while the vehicle 108 is in use, based upon the drivingperformance data. The TNC trip detector application 145 may furtherdetermine whether the period of use of the vehicle includes one or moreTNC trips based upon the locationing data (e.g., occupancy data). TheTNC route auditor application 144 may recognize route patterns of thevehicle that are indicative of TNC trips based upon both the locationingdata and driving performance data. As such, the applications 142-145 mayhave access to the received driving performance data or locationingdata. The various software applications may be executed by the samecomputer processor 162 or by different computer processors.

In some embodiments, one or more portions of the server 140 may beimplemented as one or more storage devices that are physicallyco-located with server 140, or as one or more storage devices utilizingdifferent storage locations as a shared database structure (e.g. cloudstorage). In some embodiments, server 140 may be configured to performany suitable portion of the processing functions remotely that have beenoutsourced by mobile device 110 or the on-board computer 114. Forexample, mobile device 110 may collect driving performance data orlocationing data as described herein, but may send the drivingperformance data or locationing data to server 140 for remote processingby the server 140 instead of processing the driving performance data orlocationing data locally. In other embodiments, the mobile device 110may both collect and process driving performance data or locationingdata without the server 140.

Regardless of embodiment, the driving performance data or locationingdata may be processed to determine that vehicle 108 is in a period ofuse (such as in real-time or near real-time), whether vehicle 108 isoperated manually or autonomously while the vehicle 108 is in use,determine whether the period of use of the vehicle includes one or moreTNC trips based upon the locationing data, and recognize route patternsof the vehicle that are indicative of TNC trips (and/or non-TNC trips)based upon both the locationing data and driving performance data. Insome preferred embodiments, the server 140 may subsequently transmit anotification to the mobile device 110 or the on-board computer 114 thatTNC operation is indicated, and/or TNC usage is not covered by a currentinsurance policy, based upon, at least in part, the processedlocationing data and driving performance data. For instance, the TNCusage may be determined to not be covered by a present insuranceagreement because of the presence of TNC passengers, the geolocating ofone or more mobile devices, and/or a determined route pattern.

In some embodiments, the server 140 may be part of an insurer computingsystem (or facilitate communications with an insurer computer system),and as such, may access insurer databases as needed to performinsurance-related functions. Accordingly, data received from mobiledevice 110 or on-board computer 114 may include user credentials, whichmay be verified by server 140 or one or more other external computingdevices or servers. These user credentials may be associated with aninsurance profile, which may include, for example, financial accountinformation, insurance policy numbers, a description and/or listing ofinsured assets, vehicle identification numbers of insured vehicles,addresses of insured users, contact information, premium rates,discounts, and the likes.

In this way, data received from mobile device 110 or on-board computer114 may allow server 140 to uniquely identify each insured customer. Inaddition, server 140 may facilitate the communication of the updatedinsurance policies, premiums, rates, discounts, and the likes to theirinsurance customers for their review, modification, and/or approval.Such updated information may include an endorsement or adjustment to aninsurance agreement if the policy for example covers or insures TNCtrips. The server 140 (or the insurer computing system that includes theserver 140) may generally detect whether a trip is likely to be a TNCtrip to determine risk associated with insuring a vehicle, using thelocationing data and/or driving performance data received from thefront-end components 102 (e.g., on-board computer 114 and mobile device110) via the network 130. Therefore, and advantageously, TNC trips maybe detected, and the risk of insuring a driver who makes TNC trips maybe more accurately determined.

Although the system 100 is shown to include one vehicle 108, one mobiledevice 110, one on-board computer 114, and one server 140, it should beunderstood that additional vehicles 108, mobile devices 110, on-boardcomputers 114, and/or servers 140 may be utilized. For example, thesystem 100 may include a plurality of servers 140 and hundreds of mobiledevices 110 or on-board computers 114, all of which may beinterconnected via the network 130.

Multiple mobile devices 110 belonging to the driver, non-TNC passengers,and/or TNC passengers may be within vehicle 108. For example, server 140may determine that a mobile device 110 (e.g., associated with thedriver), and another mobile device 110 (e.g., associated with anon-driver passenger) may be inside the vehicle 108. Subsequently, theserver 140 may transmit distinct locationing requests to both mobiledevices 110, receive corresponding locationing data, and thereforeoccupancy data, from each of the mobile devices 110, and determine thatvehicle 108 is operating according to a TNC trip based upon theoccupancy data received from each of the mobile devices 110. If thenon-driver passenger sits in the backseat of the vehicle 108, theoccupancy data received from the mobile device 110 associated with thedriver may include occupancy information of one or more front seats ofthe vehicle, and the occupancy data received from the mobile device 110associated with the non-driver passenger may include occupancyinformation of one or more back seats of the vehicle, for example.

Servers 140 may be dedicated for receiving each of the various types ofdata (e.g., locationing data and/or driving performance data) describedabove. Furthermore, the database storage or processing performed by theone or more servers 140 may be distributed among a plurality of servers140 in a cloud computing arrangement. This configuration may providevarious advantages, such as enabling near real-time uploads anddownloads of information, as well as periodic uploads and downloads ofdata or information. This may in turn support a thin-client embodimentof the mobile device 110 or on-board computer 114 discussed herein.

Exemplary Computer System

FIG. 2 illustrates a block diagram of a system 200 including mobiledevice 110 or an on-board computer 114 and server 140 consistent withthe system 100 of FIG. 1. The mobile device 110 or on-board computer 114may include a display 202, a controller 204, a GPS unit 206, acommunication unit 220, an accelerometer 224, a sensor array 225 (e.g.,one or more cameras, accelerometers, gyroscopes, magnetometers,barometers, thermometers, proximity sensors, light sensors, Hall Effectsensors, radar units, or any of the sensors 120 or the likes describedabove) and one or more user-input devices (not shown), such as akeyboard, mouse, microphone, or any other suitable user-input device.The communication unit 220 may provide input signals to the controller204 via the I/O circuit 216, and may also transmit sensor data, devicestatus information, control signals, or other output, which includelocationing data and/or driving performance data, from the controller204 to one or more external sensors within the vehicle 108 or server140.

Similar to the controller 155 of FIG. 1, the controller 204 may includea program memory 208, one or more processors 210 (e.g., microcontrollersor microprocessors), a RAM 212, and the I/O circuit 216, all of whichare interconnected via an address/data bus 214. The program memory 208may include an operating system 226, a data storage 228, a plurality ofsoftware applications 230, and/or a plurality of software routines 240.The operating system 226, for example, may include one of a plurality ofgeneral purpose or mobile platforms, such as the Android™, iOS®, orWindows® operating systems. Alternatively, the operating system 226 maybe a custom operating system designed for vehicle operation using theon-board computer 114.

The data storage 228 may include data such as user profiles andpreferences, application data for the plurality of applications 230,routine data for the plurality of routines 240, and other data relatedto determining the interior or passenger compartment of the vehicle 108to monitor the vehicle operator (e.g., driver) and/or passengers withinthe vehicle 108, road navigation and/or vehicle operation features. Insome embodiments, the controller 204 may also include, or otherwise becommunicatively connected to, other data storage mechanisms (not shown),such as hard disk drives, optical storage drives, or solid state storagedevices located within the vehicle 108.

As discussed with reference to the controller 155, it should beappreciated that although FIG. 2 depicts only one processor 210, thecontroller 204 may include multiple processors 210. Processor 210 may beconfigured to execute any of one or more of the plurality of softwareapplications 230 or any one or more of the plurality of softwareroutines 240 residing in the program memory 208, in addition to othersoftware applications. Similarly, the controller 204 may includemultiple RAMs 212 and multiple program memories 208. RAM 212 and programmemory 208 may be semiconductor memories, magnetically readablememories, or optically readable memories, for example.

As discussed with reference to the program memory 160 in FIG. 1, datastorage 228 may store various software applications 230 implemented asmachine-readable instructions, which may include a vehicle monitorapplication 232, a TNC route auditor application 234, and a TNC tripdetector application 236. The vehicle monitor application 232 maydetermine that vehicle 108 is in a period of use (such as determinewhether the vehicle is currently in use or being operated), and whethervehicle 108 is operated manually or autonomously while the vehicle 108is in use, based upon the driving performance data. The TNC tripdetector application 236 may further determine whether the presentperiod of use of the vehicle includes one or more TNC trips based uponthe locationing data (e.g., occupancy data). The TNC route auditorapplication 234 may recognize route patterns of the vehicle that areindicative of TNC trips based upon both the locationing data and drivingperformance data. The various software applications may be executed bythe same computer processor 210 or by different computer processors. Thevarious software applications 230 may call various software routines240, such as vehicle monitor routine 242, TNC route auditor routine 244,and/or a TNC trip detector routine 246 to execute the various softwareapplications 230.

In addition to applications and routines, the data storage 228 may storevarious data, such as expected passengers data 231, observed passengersdata 233, TNC risk index data 235, expected travel route data 236,observed travel route data 237, and/or notification data 239. In oneembodiment, the data storage 228 may include one or more of drivingperformance data 252, locationing data 253, and/or claims data 254. Inother embodiments, driving performance data 252, locationing data 253,and/or claims data 254 may be stored in database 146 managed by server140.

Expected passengers data 231 represents historical data characteristicsof non-TNC trip passengers and/or TNC trip passengers. The expectedpassengers data 231 may include data representing characteristics ofnon-TNC trip passengers and/or TNC trip passengers that may be expectedfor any one or more of the following: a particular area of traffic(e.g., an intersection, street, portion of a street, parking lot, andthe likes), a particular time, such as the time of year (e.g., aparticular date, month, and/or season), a day of the week (e.g.,Sunday-Saturday), a time of day (e.g., a particular time or a generaltime, such as “evening” or “morning”), a volume of traffic (e.g., anumber of cars per hour), and the likes. Expected passengers data 231may also represent historical data characteristics of non-TNC trippassengers and/or TNC trip passengers that have been collected in recenthistory (e.g., in the last month, the last few months, the last year,the last few years, and the likes). For example, historical datacharacteristics of non-TNC trip passengers may indicate that a passengerremained in a seat of the vehicle during the entire non-TNC trip, whichmay be measured by a seat sensor producing a constant signal.

Similarly, historical data characteristics of TNC trip passengers mayindicate that different passengers sat in a seat of the vehicle duringthe entire non-TNC trip, which may be measured by a seat sensorproducing an irregular signal. Expected passengers data 231 may betracked specific to the driver of vehicle 108, or may be a generic dataset. Observed passengers data 233 represents data characteristics ofnon-TNC trip passengers and/or TNC trip passengers of trips thatactually occurred within a certain area for the vehicle 108. Theobserved passengers data 233 may also represent policy holders (e.g.,the driver and/or passengers) associated with a particular insurancecompany, or may represent policy holders associated with multiplecompanies.

Similarly, expected travel route data 236 represents historical datacharacteristics of non-TNC trips and/or TNC trips. The expected travelroute data 236 may include data representing characteristics of non-TNCtrips and/or TNC trip passenger that may be expected for any one or moreof the following: a particular area of traffic (e.g., an intersection,street, portion of a street, parking lot, and the likes), a particulartime, such as the time of year (e.g., a particular date, month, and/orseason), a day of the week (e.g., Sunday-Saturday), a time of day (e.g.,a particular time or a general time, such as “evening” or “morning”), avolume of traffic (e.g., a number of cars per hour), and the likes.

Expected travel route data 236 may also represent historical datacharacteristics of non-TNC trips and/or TNC trips that have beencollected in recent history (e.g., in the last month, the last fewmonths, the last year, the last few years, and the likes). For example,historical data characteristics of non-TNC trips may indicate anestablished travel route that has been driven more than a pre-determinedamount of times (e.g., 30). Such travel routes, such as the travel route800 depicted in FIG. 8, may begin at a driver's home 802, end at thedriver's home 802, and have routine stops in between, such as at thedriver's work place 804 and other routine places 806, such as thegrocery store, restaurant, etc. The frequent routine stops may beindicated in the telematics data measured by the various sensors 120.

Similarly, historical data characteristics of TNC trips may indicate aunique travel route that has not been driven frequently, or less than apre-determined amount of times (e.g., 2). Such travel routes, such asthe travel route 900 depicted in FIG. 9, may begin at a driver's home902, end at a driver's home 902, and have numerous stops (e.g., morethan 10) in between at non-routine places (i.e., destinations of TNCpassengers), which may be indicated in the telematics data measured bythe various sensors 120. For example, the driver may pick up passenger912 at a non-routine place 904, pick up two additional passengers 914 atanother non-routine place 906, drop off the two additional passengers914 at a non-routine place 908, and lastly drop off passenger 912 atnon-routine place 910. The stops of such a TNC trip should coincide witha TNC passenger either entering or exiting a vehicle, and as such, thetiming of changes in telematics data (e.g., a change in vehicle loadweight) may coincide with the timing of changes in an irregular signalproduced by a seat sensor, for example. Expected travel route data 236may be tracked specific to the driver of vehicle 108, or may be ageneric data set. Observed travel route data 237 represents datacharacteristics of non-TNC trips and/or TNC trips that actually occurredwithin a certain area for the vehicle 108.

Referring back to FIG. 2, in some embodiments, the processor 210generates or collects some or all of the expected passengers data 231,observed passengers data 233, expected travel route data 236, andobserved travel route data 237 based upon the driving performance data252, locationing data 253, and/or the claims data 254 that are gatheredfrom various sources, such as vehicle 108, sensors 120, and server 140.Claims data 254 may provide supplemental information as to the frequencyof vehicle collisions for example, and more specifically, the frequencyof vehicle collisions during non-TNC trips and/or TNC trips, as well asto personnel involved in vehicle collisions, such as non-TNC trippassengers and/or TNC trip passengers for example.

As will be described herein, claims data 254 may also be used todetermine a TNC risk index for a particular trip. Claims data 254 may beassociated with actual insurance claims arising from real world vehiclecollisions, such as data scrubbed of personal information, or otherwisede-identified auto insurance claim data. Claims data 254 generallyrepresents insurance claims filed by insurance policy owners. The claimsdata 254 may identify a particular collision, the travel route that ledto the particular collision, passengers that were in the vehicle at thetime of the particular collision, policy owners, other involvedvehicles, a location where the collision occurred, property involved,repair and/or replacement costs and/or estimates, a time and date of thecollision, and/or various other information.

In one embodiment, actual claim images (such as mobile device images ofdamaged vehicles, or images acquired via vehicle-mounted cameras and/orsensors) may be analyzed to associate an amount of physical damage shownin one or more images of vehicles involved in a vehicle collision with arepair or replacement cost of the vehicles. The actual claim images maybe used to estimate repair or replacement cost for vehicles involved inpast, recent, or current vehicle collisions. The processor 210 may thenanalyze the some or all of the expected passengers data 231, observedpassengers data 233, expected travel route data 236, and observed travelroute data 237 based upon the driving performance data 252, locationingdata 253, and/or the claims data 254 to calculate a TNC risk index for aparticular trip.

The system 200 may acquire expected travel route data 236, expectedpassengers data 231, and/or the claims data 254 to assess actual tripsof interest. Particularly, the processor 210 may receive expected travelroute data 236, expected passengers data 231, and/or the claims data 254from server 140. In some embodiments, the processor 210 may transmit aquery to server 140 managing a database in order to receive expectedtravel route data 236, expected passengers data 231, and/or the claimsdata 254 from server 140.

To assess each trip of interest, driving performance data 252 (e.g.,actual data) and locationing data 253 (e.g., actual data) associatedwith the actual trip of interest may be received by processor 210 and/orstored in program memory 208, as observed travel route data 237 andobserved passengers data 233, respectively. Subsequently, the drivingperformance data 252 (e.g., actual data) and locationing data 253 (e.g.,actual data) associated with the actual trip of interest (or observedtravel route data 237 and observed passengers data 233) may be comparedagainst the acquired expected travel route data 236, expected passengersdata 231, and/or the claims data 254. For example, acquired travel routedata 236 for vehicle 108 may indicate that the vehicle 108 typicallytraverses a well-defined travel route, starting from the driver's home,heading to the driver's place of employment, and ending at the driver'shome.

Acquired expected passengers data 231 for vehicle 108 may also indicatethat the vehicle 108 typically traverses without any other passengersinside the vehicle 108. If the actual driving performance data 252 (orobserved travel route data 237) associated with the actual trip ofinterest indicates that the vehicle 108 traversed multiple places thatwere never traversed historically according to the expected travel routedata 236, and if the actual locationing data 253 (or observed passengersdata 233) indicates that the vehicle 108 traversed those places withpassengers inside the vehicle contrary to expected passengers data 231,the system 200, particularly processor 210, may assess the actual tripof interest as a TNC trip.

In other embodiments, the system 200 (e.g., the processor 210) mayacquire driving performance data 252 (e.g., actual data) and locationingdata 253 (e.g., actual data) associated with the actual trip of interest(e.g., from server 140 via wireless communication or data transmissionover one or more radio links or wireless communication channels), anddetermine, solely from the driving performance data 252 and locationingdata 253, whether the actual trip is a TNC trip or a non-TNC trip, andwhether TNC passengers or non-TNC passengers were inside the vehicleduring the trip.

In other embodiments, the server 140 may receive, via wirelesscommunication or data transmission over one or more radio links orwireless communication channels, the driving performance data 252 (e.g.,actual data) and locationing data 253 (e.g., actual data) associatedwith the actual trip of interest (or observed travel route data 237 andobserved passengers data 233) from the processor 210, and subsequentlycompare the driving performance data 252 (e.g., actual data) andlocationing data 253 (e.g., actual data) or observed travel route data237 and observed passengers data 233 against the expected travel routedata 236, expected passengers data 231, and/or the claims data 254stored in a database associated with the server 140 to assess the actualtrips of interest. In such an embodiment, the system 200, particularlyserver 140, may assess the actual trip of interest as a TNC trip, forexample.

In some embodiments, subsequent to assessing whether the actual trip ofinterest is a TNC trip, the processor 210 or server 140 may nextcalculate a TNC risk index to evaluate risk associated with insuring avehicle that participates in TNC trips. For example, in someembodiments, the processor 210 or server 140 may divide the number ofobserved TNC trips by the number of total non-TNC and TNC trips. Theprocessor 210 or server 140 may store the resulting quotient to the datastorage 228 as TNC risk index data 235 or to a database of the server140 as TNC risk index data 256. In such embodiments, a TNC risk indexvalue between 0.1 and 0.3 may indicate low risk, a TNC risk index valuebetween 0.31 and 0.6 may indicate medium risk, and a TNC risk indexvalue between 0.61 and 0.99 may indicate high risk, for example.

In other embodiments, the TNC risk index may be calculated differently.For example, in some embodiments, the processor 210 or server 140 maycalculate the TNC risk index as a count value representing the number ofTNC trips counted in a pre-determinable period of time, and if the TNCrisk index exceeds a pre-determinable threshold, the TNC risk index mayindicate high risk. Regardless of embodiment, based upon the TNC riskindex data, the process 210 or server 140 may update or adjust an auto,personal, health, life, or other insurance premium or discount toreflect risk averse behavior.

In some embodiments, subsequent to assessing that the actual trip ofinterest is a TNC trip, the processor 210 or server 140 may generate andsend a notification to the driver indicating that the TNC trip is notcovered by an insurance agreement. The processor 210 or server 140 maydetermine the identity of the driver as a party to the insuranceagreement having terms regarding the TNC usage based upon an applicationstored in the on-board computer 114, mobile device 110, or the server140 associated with the identity of the driver. If the server 140generates the notification, it may transmit, via wireless communicationor data transmission over one or more radio links or wirelesscommunication channels, the notification to the processor 210.

The notification may be sent to the driver in response to a single TNCtrip detected, in response to a plurality (e.g., exceeding apre-determinable number) of TNC trips detected, or in response to a TNCrisk index that is above a pre-determinable TNC risk index value.Because the notification may be sent to the driver when at least one TNCtrip is detected, the notification may be sent effectively based uponlocationing data 253 (e.g., geolocating of mobile devices within thevehicle) and/or based upon driving performance data 252 (e.g., a routepattern taken by the vehicle) associated with the actual trip ofinterest. In some embodiments, the server 140 may receive variousinformation as to whether the driver or autonomous vehicle accepted thealternative travel route recommendations, upon permission by the user orsettings of the autonomous vehicle. In response, the server 140 mayupdate or adjust an auto, personal, health, life or other insurancepremium or discount to reflect risk averse behavior.

The notification may also include a quote for a TNC endorsement or UBI(usage-based insurance) quote to insure TNC operation of the vehicle forone or more trips. In one aspect, the UBI quote may be for TNC insurancethat covers a specific trip along a given pre-planned route. The UBIquote may also consider or be based upon the TNC risk index value.

Exemplary TNC Operation Determination

FIG. 3 illustrates an exemplary computer-implemented method 300 fordetermining that a vehicle was in service of a TNC company, or otherwiseoperating as a TNC vehicle, during a period of operation according toone embodiment. The method 300 may be implemented, in whole or in part,by the systems 100 or 200 shown in FIGS. 1 and 2, implemented via one ormore processors (e.g., processor 210 or processor 162), transceivers,and/or sensors 120, and/or via computer-executable instructions storedon non-transitory computer-readable medium or media. Accordingly, insome embodiments, server 140 having access to driving performance data252, locationing data 253, and/or claims data 254 may carry out method300. In other embodiments, on-board computer 114 or mobile device 110having memory that stores performance data 252, locationing data 253,and/or claims data 254 may carry out method 300. The method 300 may bestored in memory (e.g., program memory 208 or other memory units) or adatabase (e.g., database 146) as one or more instructions or routines.

The method 300 may begin when a mobile device (e.g., mobile device 110),or alternatively, an on-board computer (e.g., on-board computer 114) ina vehicle transmits, via a short range communication protocol, such asBluetooth, a plurality of locationing pulse requests to an audio systemof the vehicle during a period of operation of the vehicle (block 302).The audio system may have an array of speakers disposed inside thevehicle. The locationing pulse requests may include a request to emit alocationing pulse from the array of speakers.

The method 300 may then proceed when the mobile device or on-boardcomputer, at the microphone, receives the locationing pulse from thearray of speakers (block 304). The locationing pulse may be a discreteaudio signal emitted from the array of speakers (e.g., speaker system124) in a frequency band outside an audible frequency range of humans.

The method 300 may then proceed when, in some embodiments, the mobiledevice or on-board computer determines, based upon the receivedlocationing pulse, that the vehicle was in service of a TNC company (orotherwise determine that the vehicle was operated as a TNC vehicle)during the period of operation based at least in part on passengersentering and leaving the vehicle during the period of operation (block306). For example, the mobile device 110 may analyze the receivedlocationing pulse by comparing the locationing pulse emitted from thearray of speakers (a pre-defined sequence of high frequency soundcomponents) with the received/detected locationing pulse. The presenceof passengers or objects in the vehicle 108 may alter the sequence ofhigh frequency sound components as the locationing pulse propagates fromthe array of speakers to the mobile device. The differences may beanalyzed by the mobile device or on-board computer to evaluate theconfiguration information (e.g., locationing data) concerning theinterior of the vehicle, and to further determine that the vehicle wasin service of a TNC company, or otherwise operating as a TNC vehicle,during the period of operation.

Although not pictured in FIG. 3, the mobile device or on-board computermay subsequently determine or evaluate risk (e.g., calculate a TNC riskindex) based upon the detected TNC trips, and/or may generate or displaya notification to the driver indicating that the TNC usage has beendetected, and/or TNC operation is not covered by a current insuranceagreement. In some embodiments, the mobile device or on-board computermay generate or display the notification to the driver indicating thatthe TNC usage has been detected and/or an alert that TNC operation iscurrently not covered by an insurance policy, or another alert when thedetermined risk exceeds a pre-determinable threshold.

In some embodiments, the mobile device or on-board computer may, basedupon the TNC risk index, update or adjust an auto, personal, health,life or other insurance premium or discount to reflect risk aversebehavior. The notification may be in the form of an audible, visual, orhaptic alert. For example, the notification may be downloaded by adriver of vehicle 108, displayed on a dashboard of the driver's vehicle,an on-board navigator of the driver's vehicle, a mobile device (e.g.,mobile device 110), on-board computer (e.g., on-board computer 114) orwearable electronics device display, as depicted in FIG. 10.

As shown in FIG. 10, a notification 1002 may be displayed on theon-board computer 114 of the driver's vehicle 108 that indicates that aTNC trip has been detected. In other embodiments, the notification 1002may display a message that prompts the driver to change the operation ofthe vehicle, such as engaging autonomous capabilities of the vehicle, inorder to take advantage of premium discounts. In other embodiments, thenotification 1002 may display an offer of a TNC endorsement, or a UBI orother insurance quote covering or insuring the vehicle/driver for TNCoperation. As such, the notification may enable the driver to easily beput on notice when a TNC trip causes the vehicle to be operated withoutinsurance, further enabling the driver to acquire appropriate insuranceor adjust driving behavior.

Referring back to FIG. 3, in other embodiments, the method 300 may,subsequent to the step described in block 304, proceed when a server(e.g., server 140), based upon the received locationing pulsetransmitted from the mobile device to the server, determines that thevehicle was in service of a TNC company, or otherwise being operated asa TNC vehicle, during the period of operation based at least in part onpassengers entering and leaving the vehicle during the period ofoperation. In this case, for example, the server 140 may analyze thereceived locationing pulse by comparing the locationing pulse emittedfrom the array of speakers (a pre-defined sequence of high frequencysound components) with the received/detected locationing pulse. Thepresence of passengers or objects in the vehicle 108 may alter thesequence of high frequency sound components as the locationing pulsepropagates from the array of speakers to the mobile device. In essence,upon receiving locationing data included in the locationing pulse fromthe mobile device (or generating the locationing data from thelocationing pulse), the server may analyze the locationing data toevaluate the interior of the vehicle, and to further determine that thevehicle was in service of a TNC company, or otherwise operating as a TNCvehicle, during the period of operation.

The server may then verify whether or not the vehicle and/or driver isinsured for TNC operation. For instance, the server may retrieve and/oranalyze an existing insurance policy covering the vehicle and/or driver.If the vehicle and/or driver is not insured for TNC operation under anexisting insurance policy, the server may generate an electronic quotefor a TNC endorsement, or other auto insurance covering TNC operating,and/or present the electronic quote to the driver for acceptance orapproval.

Also, although not pictured in FIG. 3, the server may subsequentlydetermine or evaluate risk (e.g., calculate a TNC risk index) based uponthe detected TNC trips, and/or may generate and/or transmit anotification to the vehicle of the driver indicating that the TNC usageis not covered by an existing insurance agreement. In some embodiments,the server may generate or transmit the notification to the vehicle ofthe driver indicating that the TNC usage is not covered by an insurancepolicy, or generation another type of notification when the determinedrisk exceeds a pre-determinable threshold. In some embodiments, theserver may, based upon the TNC risk index, update or adjust an auto,personal, health, life, or other insurance premium or discount toreflect risk averse behavior.

The notification may be in the form of an audible, visual, or hapticalert. For example, the notification may be downloaded by a driver ofvehicle 108, displayed on a dashboard of the driver's vehicle, anon-board navigator of the driver's vehicle, a mobile device (e.g.,mobile device 110), on-board computer (e.g., on-board computer 114) orwearable electronics device display. The notification may include anoffer for a TNC endorsement, and/or an offer for UBI covering TNCvehicle operation. The notification enables a driver to easily be put onnotice when a TNC trip is not covered by insurance, further enabling thedriver to acquire appropriate insurance, such as accept an offer toinsure TNC vehicle operation, or otherwise adjust driving behavior.

Additional Exemplary TNC Operation Determination

FIG. 4 illustrates an exemplary computer-implemented method 400 fordetermining that a vehicle was in service of a TNC company, or otherwiseoperating as a TNC vehicle, during a period of operation according toone embodiment. The method 400 may be implemented, in whole or in part,by the systems 100 or 200 shown in FIGS. 1 and 2, implemented via one ormore processors (e.g., processor 210 or processor 162), transceivers,and/or sensors 120, and/or via computer-executable instructions storedon non-transitory computer-readable medium or media. Accordingly, insome embodiments, server 140 having access to driving performance data252, locationing data 253, and/or claims data 254 may carry out method400. In other embodiments, on-board computer 114 or mobile device 110having memory that stores performance data 252, locationing data 253,and/or claims data 254 may carry out method 400. The method 400 may bestored in memory (e.g., program memory 208 or other memory units) or adatabase (e.g., database 146) as one or more instructions or routines.Although method 400 may thus be carried out by a mobile device, anon-board computer, or a server, for illustration purposes, FIG. 4 willbe described as being carried out by a server.

The method 400 may begin when a server (e.g., server 140) receiveslocationing data and driving performance data (block 402). Thelocationing data may be based upon the received locationing pulsetransmitted from the mobile device to the server. The drivingperformance data may be collected by front-end components 102 (e.g.,sensors 120, mobile device 110, on-board computer 114) and communicatedto the server 140 via network 130, for example.

The method 400 may then proceed when the server determines whether thevehicle is operating (block 404). For example, the server 140, viavehicle monitor application 143, may determine that a vehicle is in aperiod of use, and may further determine whether the vehicle is operatedmanually or autonomously while the vehicle is in use, based upon thereceived driving performance data. If the server determines that thevehicle is not in use, the server may determine that the vehicle was notin service of a TNC company, or otherwise not operating as a TNCvehicle, during a period of operation (block 416).

If the server determines that the vehicle is in use, the server may thendetermine whether any passengers are detected (block 406). For example,the server 140, via TNC trip detector application 145, may determinewhether the period of use of the vehicle includes one or more TNC tripsbased upon the received locationing data (e.g., occupancy data). If theserver determines that there are no passengers (e.g., no TNC passengers)in the vehicle during the period of use, the server may determine thatthe vehicle was not in service of a TNC company, or otherwise notoperating as a TNC vehicle, during the period of operation (block 416).

If the server determines that there are passengers (either TNCpassengers or non-TNC passengers) in the vehicle during the period ofuse, the server may then determine, via the TNC route auditorapplication 144 for example, whether the vehicle traversed awell-defined travel route (block 408), such as starting from thedriver's home, heading to the driver's place of employment, and endingat the driver's home for example, based upon the received drivingperformance data. If the server determines that the vehicle traversed awell-defined travel route more than a pre-determinable number of times,the server may determine that the vehicle was not in service of a TNCcompany, or otherwise not operating as a TNC vehicle, during the periodof operation (block 416).

If the server determines that the vehicle traversed a well-definedtravel route less than a pre-determinable number of times, the servermay then determine, via the TNC trip detector application 236, whetherdifferent passengers entered or left the vehicle during a particularroute or the period of use based upon the received locationing data(block 410). The stops of the particular route or during the period ofuse should coincide with a passenger either entering or exiting avehicle, and as such, the timing of changes in driving performance data,particularly telematics data (e.g., a change in vehicle load weight),may coincide with the timing of changes in locationing data,particularly an irregular signal produced by a seat sensor, for example.If the server determines that different passengers did not enter orleave the vehicle during a particular route or the period of use basedupon the received locationing data, the server may determine that thevehicle was not in service of a TNC company, or otherwise not operatedas TNC vehicle, during the period of operation (block 416). Otherwise,the server may determine that the vehicle was in service of a TNCcompany, or was actually operated as a TNC vehicle, during the period ofoperation (block 412).

After the server determines that the vehicle was in service of a TNCcompany or operated as a TNC vehicle during the period of operation, theserver may determine or evaluate risk (e.g., calculate a TNC risk index)based upon the detected TNC trips, and/or may transmit a notification tothe driver indicating that the TNC usage is not covered by a currentinsurance agreement (block 414). As described above with respect to FIG.3, in some embodiments, the server may transmit the notification to thedriver indicating that the TNC usage is not presently covered byinsurance, or indicating that the determined risk exceeds apre-determinable threshold. In some embodiments, the server may, basedupon the TNC risk index, update or adjust an auto, personal, health,life, or other insurance premium or discount, or generate an insurancequote, to reflect risk averse behavior. The notification may include anoffer for a TNC endorsement, or an UBI or other insurance quote coveringTNC operation.

The notification may be in the form of an audible, visual, or hapticalert. For example, the notification may be downloaded by a driver ofvehicle 108, displayed on a dashboard of the driver's vehicle, anon-board navigator of the driver's vehicle, a mobile device (e.g.,mobile device 110), on-board computer (e.g., on-board computer 114) orwearable electronics device display. The notification enables a driverto easily be put on notice when a TNC trip may not be covered by aninsurance agreement, further enabling the driver to adjust drivingbehavior.

Insurance companies may adjust rates based upon how often a particulardriver participates in TNC trips. This rate adjustment may be based uponan estimate, or may be implemented as part of a dynamic rate policy. Forexample, an insurance company may implement a dynamic rate responsive toa driver's real-time behavior, and may reward risk-averse drivers. Thus,the rate may dynamically increase or decrease as a driver participatesin more or less TNC trips, respectively.

Exemplary Vehicle Interiors

FIG. 5 illustrates an exemplary interior 500 of a vehicle on which themethods described herein may be implemented. As shown, the interior 500of vehicle 108 may include a speaker system including a plurality ofspeakers 506. In some embodiments, the mobile device 110 (or on-boardcomputer 114, not illustrated) may transmit a locationing pulse requestto one or more speakers 506 over a short-range communication protocol(e.g., Bluetooth).

In such embodiments, as indicated in FIG. 6, the on-board computer 114of interior 600 of vehicle 108 may display a message indicating that themobile device 110 is connected to the vehicle 108 via Bluetooth. Thelocationing pulse request may include a request for the one or morespeakers 506 to emit a locationing pulse. In response to receiving thelocationing pulse request, the speakers 506 may emit a locationing pulseback to the mobile device 110, which may in turn receive/detect thelocationing pulse via a microphone 512 of the mobile device 110. Themobile device 110 may process the locationing pulse and furtherdetermine configuration information (e.g., locationing data) concerningthe interior 500 of the vehicle 108, such as whether a seat is occupiedby a person 508 or object 514, detecting passengers that have entered orleft the vehicle over a period of operation of the vehicle, or thelocations of other mobile devices 510. If the mobile device 110determines the locations of other mobile devices 510, the on-boardcomputer 114 of interior 700 of vehicle 108 may display a messageindicating that another mobile device (e.g., mobile device 510)associated with a non-driver passenger has been detected via Bluetoothas indicated in FIG. 7, in some embodiments.

Exemplary Machine Learning

Machine learning techniques have been developed that allow parametric ornon-parametric statistical analysis of large quantities of data. Suchmachine learning techniques may be used to automatically identifyrelevant variables (i.e., variables having statistical significance or asufficient degree of explanatory power) from data sets. This may includeidentifying relevant variables or estimating the effect of suchvariables that indicate actual observations in the data set. This mayalso include identifying latent variables not directly observed in thedata, viz. variables inferred from the observed data points. In someembodiments, the methods and systems described herein may use machinelearning techniques to identify and estimate the effects of observed orlatent variables such as vehicle location, time of day, presence ofpassengers, a particular area of traffic, a volume of traffic (e.g., anumber of cars per hour), or other such variables that influence therisks associated with transportation network company trips.

Some embodiments described herein may include automated machine learningto collect driving performance data or locationing data, detect/processthe locationing pulse, determine configuration information (e.g.,locationing data) concerning the interior of the vehicle, such aswhether a seat is occupied by a person or object, detecting passengersthat have entered or left the vehicle over a period of operation of thevehicle, or the locations of other mobile devices, recognize routepatterns of the vehicle that are indicative of TNC trips based upon boththe locationing data and driving performance data, generate or transmitnotifications to drivers or non-driver passengers, and/or perform otherfunctionality as described elsewhere herein.

Although the methods described elsewhere herein may not directly mentionmachine learning techniques, such methods may be read to include suchmachine learning for any determination or processing of data that may beaccomplished using such techniques. In some embodiments, suchmachine-learning techniques may be implemented automatically uponoccurrence of certain events or upon certain conditions being met. Useof machine learning techniques, as described herein, may begin withtraining a machine learning program, or such techniques may begin with apreviously trained machine learning program.

A processor or a processing element (e.g., mobile device 110, on-boardcomputer 114, and/or server 104 of FIGS. 1 and 2) may be trained usingsupervised or unsupervised machine learning, and the machine learningprogram may employ a neural network, which may be a convolutional neuralnetwork, a deep learning neural network, or a combined learning moduleor program that learns in two or more fields or areas of interest.Machine learning may involve identifying and recognizing patterns inexisting data, in order to facilitate making predictions. Models may becreated based upon example inputs of data in order to make valid andreliable predictions for novel inputs.

Additionally or alternatively, the machine learning programs may betrained by inputting sample data sets or certain data into the programs,such as mobile device, vehicle, or smart infrastructure sensor and/orcontrol signal data, and other data discussed herein. The machinelearning programs may utilize deep learning algorithms that areprimarily focused on pattern recognition, and may be trained afterprocessing multiple examples. The machine learning programs may includeBayesian program learning (BPL), voice recognition and synthesis, imageor object recognition, optical character recognition, and/or naturallanguage processing—either individually or in combination. The machinelearning programs may also include natural language processing, semanticanalysis, automatic reasoning, and/or machine learning.

In supervised machine learning, a processing element may be providedwith example inputs and their associated outputs, and may seek todiscover a general rule that maps inputs to outputs, so that whensubsequent novel inputs are provided the processing element may, basedupon the discovered rule, accurately predict the correct or a preferredoutput. In unsupervised machine learning, the processing element may berequired to find its own structure in unlabeled example inputs. In oneembodiment, machine learning techniques may be used to extract thecontrol signals generated by computer systems or sensors, and under whatconditions those control signals were generated.

The machine learning programs may be trained with vehicle-mounted,home-mounted, and/or mobile device-mounted sensor data to identifycertain customer activity, such as routine travel (e.g., non-TNC trips)or non-routine travel (e.g., TNC trips) at certain times of day.

After training, machine learning programs (or information generated bysuch machine learning programs) may be used to evaluate additional data.Such training data may be related to past and/or historical datagathered by smart vehicles, mobile device, or smart infrastructure, orother similar data to be analyzed or processed. The trained machinelearning programs (or programs utilizing models, parameters, or otherdata produced through the training process) may then be used fordetermining, assessing, analyzing, predicting, estimating, evaluating,or otherwise processing new data not included in the training data. Suchnew or additional data may be related to current, up-to-date, orreal-time data gathered by smart vehicles, mobile device, smartinfrastructure, or other sensors and cameras, or other similar data tobe analyzed or processed. Such trained machine learning programs may,thus, be used to perform part or all of the analytical functions of themethods described elsewhere herein.

Additional Considerations

With the foregoing, an insurance customer (e.g., a driver) may opt-in toa rewards, insurance discount, or other type of program. After theinsurance customer provides their affirmative consent, an insuranceprovider remote server may collect data from the customer's mobiledevice, smart vehicle, autonomous or semi-autonomous vehicle, smart homecontroller, or other smart devices—such as with the customer'spermission or affirmative consent. The data collected may be related tosmart or autonomous vehicle functionality, smart home functionality (orhome occupant preferences or preference profiles), and/or insured assetsbefore (and/or after) an insurance-related event, including those eventsdiscussed elsewhere herein. In return, those insured may receivediscounts or insurance cost savings related to auto, home, life,renters, personal articles, mobile, and other types of insurance fromthe insurance provider.

All of the foregoing methods discussed herein may be include additional,less, or alternate actions, including those discussed elsewhere herein.All of the foregoing methods may be implemented via one or more local orremote processors, transceivers, servers, and/or sensors, and/or viacomputer-executable instructions stored on computer-readable medium ormedia. The foregoing devices and systems may also include additional,less, or alternate functionality, including that discussed elsewhereherein.

Of course, the applications and benefits of the systems, methods andtechniques described herein are not limited to only the above examples.Many other applications and benefits are possible by using the systems,methods and techniques described herein.

Furthermore, when implemented, any of the methods and techniquesdescribed herein or portions thereof may be performed by executingsoftware stored in one or more non-transitory, tangible, computerreadable storage media or memories such as magnetic disks, laser disks,optical discs, semiconductor memories, biological memories, other memorydevices, or other storage media, in a RAM or ROM of a computer orprocessor, etc.

Moreover, although the foregoing text sets forth a detailed descriptionof numerous different embodiments, it should be understood that thescope of the patent is defined by the words of the claims set forth atthe end of this patent. The detailed description is to be construed asexemplary only and does not describe every possible embodiment becausedescribing every possible embodiment would be impractical, if notimpossible. Numerous alternative embodiments could be implemented, usingeither current technology or technology developed after the filing dateof this patent, which would still fall within the scope of the claims.

While the preferred embodiments of the invention have been described, itshould be understood that the invention is not so limited andmodifications may be made without departing from the invention. Thescope of the invention is defined by the appended claims, and alldevices that come within the meaning of the claims, either literally orby equivalence, are intended to be embraced therein. Finally, unless aclaim element is defined by reciting the word “means” and a functionwithout the recital of any structure, it is not intended that the scopeof any claim element be interpreted based upon the application of 35U.S.C. § 112(f). The patent claims at the end of this patent applicationare not intended to be construed under 35 U.S.C. § 112(f) unlesstraditional means-plus-function language is expressly recited, such as“means for” or “step for” language being explicitly recited in theclaim(s).

The following considerations also apply to the foregoing discussion.Throughout this specification, plural instances may implement operationsor structures described as a single instance. Although individualoperations of one or more methods are illustrated and described asseparate operations, one or more of the individual operations may beperformed concurrently, and nothing requires that the operations beperformed in the order illustrated. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of “a” or “an” is employed to describe elements andcomponents of the embodiments herein. This is done merely forconvenience and to give a general sense of the invention. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs forgenerating, modifying, and/or using driver profiles through theprinciples disclosed herein. Thus, while particular embodiments andapplications have been illustrated and described, it is to be understoodthat the disclosed embodiments are not limited to the preciseconstruction and components disclosed herein. Various modifications,changes and variations, which will be apparent to those skilled in theart, may be made in the arrangement, operation and details of the methodand apparatus disclosed herein without departing from the spirit andscope defined in the appended claims.

What is claimed:
 1. A computer-implemented method of detecting use of avehicle for transportation network company (TNC) trips, the methodcomprising: transmitting a plurality of locationing pulse requests froma mobile device in a vehicle to an audio system of the vehicle during aperiod of operation of the vehicle, the audio system having an array ofspeakers disposed inside the vehicle, and the locationing pulse requestsincluding a request to emit a locationing pulse from at least one of thearray of speakers; receiving the locationing pulse at a microphone ofthe mobile device; and determining, based upon the receiving operationthat the vehicle was in service of a TNC company during the period ofoperation based at least in part on passengers entering and leaving thevehicle during the period of operation.
 2. The computer-implementedmethod of claim 1, further comprising: determining an identity of adriver of the vehicle, the driver being party to an insurance agreementinsuring the vehicle, the insurance agreement having terms regarding TNCusage of the vehicle; and transmitting a notice to the driver that TNCusage is not covered by the insurance agreement based upon the operationthat determines the presence of a TNC passenger inside the vehicle. 3.The computer-implemented method of claim 2, wherein determining theidentity of the driver is based upon an application executing on themobile device, the application having the identity of the driverassociated therewith.
 4. The computer-implemented method of claim 1,wherein the determining comprises detecting a physical object occupyinga seat of the vehicle.
 5. The computer-implemented method of claim 1,wherein the receiving comprises detecting a plurality of TNC passengers,each of the plurality of TNC passengers having entered and left thevehicle over a period of operation of the vehicle.
 6. Thecomputer-implemented method of claim 1, wherein determining presence ofthe TNC passenger further comprises geolocating the mobile device. 7.The computer-implemented method of claim 1, wherein determining presenceof the TNC passenger is further based upon a driving pattern of thevehicle.
 8. A system for detecting use of a vehicle for a transportationnetwork company (TNC) comprising: a memory configured to storenon-transitory computer executable instructions; and a processorconfigured to interface with the memory, wherein the processor isconfigured to execute the non-transitory computer executableinstructions to cause the processor to: determine that a vehicle is in aperiod of use, the vehicle having an audio system; transmit a pluralityof requests to the vehicle to emit a locationing pulse from the audiosystem; receive a plurality of sets of locationing data from one or moremobile devices inside the vehicle, the plurality of sets of locationingdata including the presence of passengers in the vehicle; and determinewhether the period of use of the vehicle includes one or more TNC trips.9. The system of claim 8, wherein the plurality of requests to thevehicle to emit a locationing pulse are received by one of the one ormore mobile devices inside the vehicle.
 10. The system of claim 8,wherein the processor is further configured to: recognize route patternsof the vehicle that are indicative of TNC trips based upon the pluralityof sets of locationing data, and wherein the locationing data furtherincludes a geographical location of at least one of the one or moremobile devices inside the vehicle.
 11. The system of claim 8, whereinthe audio system includes an array of speakers.
 12. The system of claim8, wherein the audio system includes an ultrasonic beacon.
 13. Thesystem of claim 8, wherein the processor is further configured todetermine whether the vehicle is operated manually or autonomously whilethe vehicle is in use.
 14. The system of claim 8, wherein the processoris further configured to receive mobile device information, the mobiledevice information include Bluetooth connection information of the oneor more mobile devices inside the vehicle.
 15. A computer-implementedmethod of detecting transportation network company (TNC) trips in avehicle, the method comprising: determining that a first mobile deviceis inside a vehicle, the vehicle being operated by an operator andhaving an array of audio speakers; transmitting at least a firstlocationing request to the first mobile device, the first, locationingrequest including a request to emit a locationing pulse from one or moreof the audio speakers, receiving first locationing data from the firstmobile device, the first locationing data including first occupancy dataof seats in the vehicle; determining that a second mobile device isinside the vehicle; transmitting at least a second locationing requestto the first mobile device, the second locationing request including arequest to emit a locationing pulse from one or more of the audiospeakers; receiving second locationing data from the second mobiledevice, the second locationing data including second occupancy data ofseats in the vehicle; and determining that the vehicle is operatingaccording to a TNC trip based upon the first occupancy data and thesecond occupancy data.
 16. The computer-implemented method of claim 15,wherein the first occupancy data includes occupancy of one or more frontseats of the vehicle and the second occupancy data includes occupancy ofone or more back seats of the vehicle.
 17. The computer-implementedmethod of claim 15, wherein the first mobile device is associated withthe operator of the vehicle and the second mobile device is associatedwith a TNC passenger of the vehicle.
 18. The computer-implemented methodof claim 15, wherein the operation that determines that the vehicle isbeing operated by the operator includes receiving a notification of theidentity of the operator from an application executing on the firstmobile device.
 19. The computer-implemented method of claim 15, whereinthe operation that determines that the vehicle is being operated by theoperator includes receiving a notification that the first mobile deviceis communicatively coupled to the vehicle and capable of controlling theone or more audio speakers.
 20. The computer-implemented method of claim15, wherein the operation that determines that the vehicle is operatingaccording to a TNC trip further includes repeatedly receivinglocationing data from the first mobile device, the repeatedly receivedlocationing data including data indicative of a plurality of sets ofpassengers entering and leaving the vehicle while the vehicle is beingoperated by the operator.